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niis application is a continuation of co-pending application filed 12/05/2000 
under serial number 09/730,639, which is a continuation-in-part application of a co- 
pending applications entitled "SYSTEM, METHOD AND ARTICLE OF 
MANUFACTURE FOR SHADOW MAPPING" filed 08/16/00 under serial number 
09/640,505; and "SYSTEM, METHOD AND ARTICLE OF MANUFACTURE 
FORPKEL SHADERS FOR PROGRAMMABLE SHADING" filed 05/31/00 
under serial number 09/585.809, issued under U.S. Pat. No.: 6,532,013, which are 
both incorporated herein by reference in its entirety. THis application is also related 
to a co-pending application entitled "GRAPHICS PIPELINE INCLUDING 
COMBINER STAGES" filed 03/22/99 under serial number 09/273,975, issued 
under U.S. Pat. No.: 6,333,744, and naming David B. Kirk, Matthew Papakipos. 
Shaun Ho, Walter Donovan, and Curtis Priem as inventors, and which is 
incorporated herein by reference in its entirety. 

TTiiri n nn THK INVENTION 

nxe present invention relates to computer graphics, and more particularly to 
shadow mapping in a graphics pipeline. 

RAPlcnROUNP THF. INVENTION 

A major objective in graphics rendering is to produce unages that are so 
realistic that the observer believes the image is real. A fimdamental difficulty in 
achieving total visual realism is the complexity of accurately representing real world 
visual effects. A scene can include a wide variety of textures, subtle color 
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gradations, reflections, translucency, etc. One important way to make images more 
realistic is to determine how objects in a scene cast shadows and then represent these 
shadows in the rendered image. Shadows enhance the realism of an image because 
they give a two-dimensional image a three-dimensional feel. 

5 

The addition of shadows to the rendering of a complex model can greatly 
enhance the understanding of that model's geometry. The human visual system uses 
shadows as a cue for depth and shape. Consequently, shadows are very useful for 
conveying the three dimensional nature of rendered objects and for adding realism to 
10 computer generated scenes. 

Generally, shadowing is similar to hidden surface removal. In hidden surface 
removal, objects or portions thereof are obscured because they are behind another 
object. For hidden surface removal, the point of reference for determining if an 

15 object is obscured is called a viewing point. For shadowing, objects or portions 
thereof are obscured because they are in the shadow of another object. In the 
shadowing case, the point of reference for determining if an object is obscured is a 
source Ught point. While many approaches exist for shadow mapping, depth map- 
based shadow algorithms are commonly used in graphics pipelines. Examples of 

20 such depth map-based shadow mapping algorithms are set forth in: 

1) Lance Williams. Casting curved shadows on curved surfaces. In 
Proceedings ofSIGGRAPH'78, pages 270-274, 1978; 

25 2) Reeves, D. H. Salesin, R. L. Cook. Rendering antialiased shadows with 

depth maps. In Proceedings ofSIGGRAPH'87, pages 283-291, 1987; and 

3) M. Segal, C. Korobkin, R. van Widenfelt, J. Fordan, P. Haeberli. Fast 
Shadows and Lighting Effects Using Texture Mapping. In Proceedings of 
30 SIGGRAPH'92, pages 249-252, 1992. 
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which are each incorporated herein by reference in their entirety. 



Prior Art Figure 1 illustrates one depth map-based shadow algorithm 100 for 
generating realistic shadows, hi such approach, there are two rendering passes 102 
and 104. In the first pass 102, the scene is rendered from the point of view of a light 
source. The result is a depth map 106, or shadow map, which is essentially a two- 
dimensional function indicating the depth of the closest pixels to the light. In 
particular, each primitive, i.e. triangle, is scan-converted into pixels. A depth value, 
ziight, of the scanned fragment is interpolated across the primitive, and then is z- 
tested using a standard z-value (or any other depth value representation) buffer 
algorithm before being written out to the depth map 106. For additional information 
regarding such algorithm, reference may be made to the previously mentioned 
references in addition to: E. Catmull. A hidden surface Algorithm with Anti- 
AUasing. In Siggraph 78, Page 6-11. 1978, which is incorporated herein by reference 
in its entirety. 

Prior Art Figure 2 A illustrates the prior art technique 200 of building the 
shadow map using the standard z-buffer algorithm. As shown, distances 202 
between a light source 204 and exposed surfaces of objects 206 are collected from a 
z-buffer. Depth values which are representative of the distances 202 are then 
utilized to generate the depth map 106. 

For reasons that will soon become apparent, a polygon offset fiinction maybe 
performed in operation 108 for resolving a common self-shadowing aliasing 
problem. As an option, the polygon offset operation may include the 
"glPolygonOffset" operation in accordance with the OpenGL® programming 
language. 

hi the second pass 104, the scene is rendered fix)m the eye space. During the 
second pass 104, each primitive is scanned into the screen from the eye space. 
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However, the position (x,y,z) in the eye space can be transformed via a standard 
projective texture mapping operation 110 into the light space to get a texture 
coordinates (s.t,r), where (s,t) are the texture coordinates of the sampled three- 
dimensional point projected on the depth map 106, while r is the depth value that 
corresponds to the distance of the sampled point to the hght source. In the second 
pass it is important to note that the distance value, r. can possibly be scaled by a 
percentage value, hence is offset by a small percentage amount using the texgen 
matrix or a vertex program. 

Thereafter, in operation 112, the depth value at the sampling point, r, is then 
compared with the offset depth value, z„^., stored in the depth map 106 generated in 
the first pass 102 to yield a light-occlusion result, i.e. r > z^, if the sampled point is 
behind some objects which are closer to the light, hence it is in the shadow of those 
objects. The resultant binary shadow values are then used to shade the current 
15 scamied object, resulting in shadow effects. Prior Art Figure 2B illustrates the 

various variables associated with the calculations carried out during the second pass 
104. Finally, a shadow modulation operation 114 is performed, the details of which 
will be set fordi hereinafter. 

Since this two-pass approach requires resampling the depth map 106 in the 
second pass 104. the problem of self-shadow aliasing may occur. Prior Art Figure 
2C illustrates such aliasing problem that arises when shadow mapping in accordance 
with Prior Art Figures 1-2B. In particular, complications arise when various points 
on the objects 206 are rendered in light space via a single texel 210 during the first 
25 pass 102. and subsequently rendered by way of separate pixels 212 in eye space 
during the second pass 104. 

Prior Art Figure 3A illustrates the offset operation 108 of Prior Art Figure 1 
which represents a solution to the aliasing problem of Prior Art Figure 2C. As 
30 shown,thedepthvalue.z„^.,maybeboundedbythe«glPolygonOffset"operation. 



20 
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In particular, the "glPolygonOffset" operation includes calculating an offset value, o, 
using Prior Art Equations A. 

Eq uations A 
ziight = z + o, where: 
o = m*factor + r*units, where: 
m = max(abs(5z/5x), abs(5z/5y)), where 
■ r is defined in Prior Art Figure 2B, 

- factor = a scalar that scales the maximum depth slope m of the 

polygon; and 

- units = a scalar that scales an implementation-dependent 
constant that relates to the usable resolution of the depth 
buffer. Both factor and units may be positive or negative. 

See equations 3.6 and 3.7 of the OpenGL 1.2.1 specification that can be 

found at K ^ //wwwonend.c rr^ .nt.tion/Snecs.htmK and which is 

incorporated herein by reference. 



By offsetting the depth value, z.igh. , the self-shadow aliasing of Prior Art 
Figure 2C is avoided. In particular, the offset operation dynamically compensates 
25 for the depth variation within each texel of the depth map 106. 

Prior Art Figure 3B illustrates a limitation associated with the prior art 
solution of Prior Art Figure 3A. In some instances the values 8z/5x and 5z/5y of 
Equations A are unbounded due to the severe depth slopes of the nearly edge-on 
30 objects 206. This can lead to erroneous results, i.e. false shadows, when using the 
offset equation set forth hereinabove. 
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Various additional prior art techniques have been developed for addressing 
the problem of self-shadow aliasing. For example, shadows can be softened at the 
shadow boundaries, as set forth in the following document: W. Reeves. D. H. 
Salesin, R. L. Cook. Rendering antialiased shadows with depth maps. In 
Proceedings ofSIGGRAPH'87, pages 283-291, 1987, which is incorporated herein 
by reference in its entirety. Variations of this technique are widely used and 
implemented for real or non-real time systems. Yet another solution includes the 
"SGIX_shadow" operation in accordance with the OpenGL® programming language. 

Other techniques that can be used to suppress aliasing artifacts include: 

1) Increasing the shadow map spatial resolution. This increases the number 
of depth samples to compare against, which results in a more accurate shadow. 

2) Jittering the shadow map samples by modifying the projection in the 
texture transformation matrix. The results of the depth comparisons can then be 
averaged to smooth out shadow edges. 

20 3) Modifying the texture projection matrix so that the r values are biased by a 

small amount. Further, the r values may be scaled, thus moving the objects a little 
closer to the light. This prevents sampling errors from causing a curved surface to 
shadow itself This r scaling can also be done with the offset operation. 



15 



25 



Additional solutions to the self-shadowing aliasing problem are set forth in: 

1) A. Woo. The Shadow Depth map revisited. In Graphics Gem III, pages 
338-342, 1992; 

30 2) M. Woo, J. Neider, T. Davis. In OpenGL programming Guide, second 

edition, versionl. 1.1997; 
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3) M Kilgaid. Shadow Mapping with Today's OpenGL Hardware. GDC 
2000: Advanced OpenGL Game Development, 2000; 

4) Wolfgang Heidrich, PhD thesis, 1999; 

5) Alan Watt and Mark Watt, Advanced Animation and Rendering 
Techniques. By ACM Press, New York, New York. 1992, which are each 
incorporated herein by reference in their entirety. 



While the foregoing techniques address the self-shadow aliasing problem by 
reducing the associated affects, they still merely provide a balance between 
efficiency and limitation issues. There is thus a need for an improved shadowing 
algorithm in a graphics pipeline that exploits the strengths of the prior art techniques 
1 5 such as the offset operation, while avoiding the problems and limitations associated 
therewith. 

In operation 114, a shadow modulation process with the current standard 
OpenGL graphics pipeline is carried out in a single function: 



Color = (1-s )*(color_amb + color_diff + color_spec). 



where s is a shadow variable, Color_difif is a diffuse color variable, Color_spec is a 
specular color variable, and Color_amb is an ambient color variable. This technique 
25 is very limited in its flexibility since it shadows a superposition of diffuse color and 
ambient color by simply adding them before entering the pixel shading logic. There 
is thus a further need for a shadowing algorithm in a graphics pipeline that includes a 
flexible way of implementing shadow modulation. 
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DlSCLOSURE OF THE INVENTION 



10 



A system, method and article of manufacture are provided for shadow 
mapping while rendering a primitive in a graphics pipeline. Initially, an offset 
operation is performed in order to generate a depth value while rendering a 
primitive. Further, a value of a slope associated with a triangle is identified. 
Thereafter, the depth value is conditionally clamped to the depth gamut of the 
triangle based on the value of the slope of the triangle. 



In one embodiment of the present invention, the shadow mapping process 
includes rendering the primitive from a light space perspective. The offset operation 
may include a polygon offset operation in accordance with the OpenGL® 
programming language. Further, the depth value may be clamped if the value of the 
1 5 slope is greater than a predetermined amount. 

In another embodiment of the present invention, the clamping may include 
identifying vertex depth values of vertices of the primitive, and comparing at least 
one of the vertex depth values with the depth value generated by the offset operation. 
20 Thereafter, the depth value generated by the offset operation may be clamped based 
on the comparison. 

hi one aspect, the depth value generated by the offset operation may be 
clamped to the offset operation depth value if such offset operation depth value is 
25 less than the greatest vertex depth value. Further, the depth value generated by the 
offset operation may be clamped to the greatest vertex depth value if the greatest 
vertex depth value is less than the depth value generated by the offset operation. 

In another aspect, the depth value generated by the offset operation may be 
30 clamped to the offset operation depth value if such depth value is greater than the 
least vertex depth value. Further, the depth value generated by the offset operation 
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n.ay be clamped to the least vertex depth value if the least vertex depth value is 
greater than the depth value generated by the offset operation. 

In accordance with another embodiment of the present invention, a technique 
5 may be provided for performing shading calculations in a graphics pipeline. 

Initially, a first shading calculation may be performed in order to generate output, 
after which such output may be saved. A second shading calculation may also be 
performed using the saved output in order to generate further output. 

10 In one embodiment, the first shading calculation may include: 

[(l-s)*(Color_diff + Color_spec)] 

for generating an output A, and the second shading calculation may include: 

[Color___amb + A], 

where s is a shadow variable, Color.diff is a diffuse color variable, Color_spec is a 
specular color variable, and Color.amb is an ambient color variable. It should be 
noted that s, the shadow variable, generally takes values in the range 0.0 to 1.0, 
where 0.0 could represent being completely unshadowed and 1 .0 being completely 
shadowed. The shadow variable s is computed by normal texture filtering of the 
results obtained in the second pass of the shadow algorithm. 



15 



20 



25 



30 



In yet another embodiment, the first shading calculation may include: 
[((1-s)* Color_diff) + Color_amb] 
for generating an output A. and the second shading calculation may include: 
[A*Texture_det + (1-s)* Color_spec], 
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where s is a shadow variable, Color_diff is a dif&se color variable. Color.spec is a 
specular color variable, Color.amb is an ambient color variable, and Texture_det is 
a detail texture variable. 

As such, the first and second shading calculations may together include a diffiise 
color variable, a specular color variable, and an ambient color variable, while ensuring 
that such variables remain decoupled. These and other advantages of the present 
invention will become apparent upon reading the following detailed description and 
studying the various figures of the drawings. 
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RrirF DESCPIPTION OF TH R DRAWINGS 

The foregoing and other aspects and advantages are better understood from 
5 the following detailed description of a preferred embodiment of the invention with 
reference to the drawings, in which: 

Prior Art Figure 1 illustrates a graphics pipeline with which shadow mapping 
may be performed in accordance with the prior art; 

10 

Prior Art Figure 2A illustrates a prior art technique of building shadow maps; 
Prior Art Figure 2B illustrates a prior art technique of rendering shadow 

maps; 

15 

Prior Art Figure 2C illustrates an aliasing problem that arises when shadow 
mapping in accordance with Prior Art Figures 1-2B; 

Prior Art Figure 3A illustrates a prior art solution to the aliasing problem of 
20 Prior Art Figure 2C; 

Prior Art Figure 3B illustrates a limitation associated with the prior art 
solution of Prior Art Figure 3A; 

25 Figure 4 illustrates a hardware implementation for programmable shading in 

accordance with one embodiment of the present invention; 

Figure 5 illustrates a graphical representation of the edge distances generated 
by the rasterizer in accordance with one embodiment of the present invention; 

30 
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Figure 6 illustrates a flow diagram depicting the mamier in which the shading 
calculations are interweaved with the texture fetch operations in a plurality of 
iterations in accordance with one embodiment of the present invention; 

5 Figure 7 illustrates a point within a primitive that is capable of being defined by 

barycentric weights; 

Figure 8 illustrates a graphics pipeline with which shadow mapping may be 
performed in accordance with Ihe present invention; 

10 

Figure 9 illustrates a method for shadow mapping while rendering a primitive 
in a graphics pipeline; 

Figure 9a illustrates an exemplary method by which the depth value is 
1 5 clamped in operation 906 of Figure 9; 

Figure 10 is a diagram illustrating the manner in which the depth value is 
clamped in accordance with the method of Figure 9; and 

20 Figure 11 illustrates a method for performing shading calculations in a 

graphics pipeline in accordance with one embodiment of the present invention. 
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nr«;rRIPTION OF THF PREFERRED EMBODIMENTS 

Figures 1-3B illustrate the prior art. Figure 4 shows an illustrative hardware 
implementation of the present invention. As shown, included is a set-up module 
402, a rasterizer 404, a shader module 406, a texture fetch module 408, and a 
combiner 410 coupled to form a portion of a graphics processing pipeline 400. For 
reasons that will soon become apparent, a feedback loop 409 is coupled between an 
output of the shader module 406 to an input thereof. It should be noted that the set- 
up module 402, rasterizer 404, and combiner 410 operate in a conventional manner 
as set forth during reference to Figure 1. While the combiner 410 may be 
implemented in any desired mamier, one exemplary implementation is disclosed in a 
co-pending application entitled "GRAPHICS PIPELINE INCLUDING COMBINER 
STAGES" filed 03/22/99 under serial number 09/273,975, issued under U.S. Pat. 
No.: 6,333,744, and naming David B. Kirk, Matthew Papakipos, Shaun Ho, Walter 
Donovan, and Curtis Priem as inventors, and which is incorporated herein by 
reference in its entirety. 

With continuing reference to Figure 4, the various inputs and outputs are 
shown for each of the components. As shown, the rasterizer 404 generates edge 
distances which are used by the shader module 406 and texture fetch module 408. 

Also shown in Figure 4 is an optional feedback first-in first-out (FIFO) 
buffer. When the feedback loop 409 is not utilized, the temporary data calculated 
internally by the present invention may be dropped before being sent to the texture 
fetch module 408. 

As an option, however, the shader module 406 may be reused, and some of 
this data Oike the barycentric coordinates) may be reused each time a particular 
group of pixels, or "quad," goes through the shader module 406. If new colors are 
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generated during one pass, these colors may continuously be associated with the 
quad on subsequent passes. Further, more than one triangle may be processed at a 
time while employing the feedback loop 409, since data from several triangles 
generally appears while waiting for the texture fetch module 408 to calculate an 
5 individual texture look-up. 

To address this, the loopback FIFO 407 may be utilized to hold barycentric 
weights, colors from previous passes, triangle information, and additional scheduling 
information to keep track of what the shader module 406 is supposed to do each 

10 pass. The FIFO 407 may include a plurality of bits that can be reconfigured to store 
whatever piece of data is appropriate. When the texture requests for a particular 
quad are sent to the texture fetch module 408, the associated data may also be placed 
in the FIFO 407. When the texture requests complete, the results may be combined 
with the data from the FIFO 407, and a small portion of logic may decide whether to 

1 5 send the completed quad to the combiner 410, or back around for another pass at the 
shader module 406. 

Figure 5 iUusfrates a graphical representation of the edge distances generated 
by the rasterizer 404. As shown, the edge distances (eo, e,, ez) represent a 
20 perpendicular distance 500 from an edge 502 of a primitive 504 to a pixel 506 within 
the primitive 504. Such edge distances (eo. e,, ez) thus identify the location of the 
pixel 506 within the primitive 504. 

As a function of the shading calculations, various texture look-up operations 
25 may be carried out utilizing the texture look-up module 408 in order to obtain output 
having appropriate texture map colors. To accomplish this, texture coordinates may 
be sent to the texture look-up module 408. In response thereto, texture information 
is received from the texture look-up module 408. Such texture information may take 
any form including, but not limited to filtered texture color, etc. 

30 
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During the course of use, the feedback loop 409 may be used for performing 
another shading calculation using the texture information from the texture look-up 
module 408 in order to generate further output. As an option, the texture 
information may include filtered texture look-up values for use in retrieving further 

5 texture information when the texture information retrieval operation is repeated. 
The present invention thus allows repeated texture information retrieval and shading 
calculations in an iterative, programmable mamier. In other words, each iteration 
may be programmed to do a desired shading calculation with or without a texture 
look-up. where each subsequent iteration may use results of previous texture look- 

1 0 ups for generating fiirflier results. 

In one embodiment of the present invention, at least a pair of texture look-up 
modules is coupled to a pair of shading modules which together constitute at least 
four logical modules. Further, the system may be capable of performing both 
15 interpolation and shading calculations including pre-texture shading calculations and 
post-texture shading calculations 

Figure 6 illustrates a flow diagram depicting the mamier in which the shading 
calculations are interweaved with the texture fetch operations in a plurality of 

20 iterations 600. As shown, each iteration 600 includes a shading calculation 602. 
During each shading calculation 602, a decision 604 maybe made as to whether a 
texture look-up may be performed. If so, texture information may be retrieved 
during a texture look-up operation 605. Also during each iteration 600. another 
decision 606 is made as to whether an additional shading operation 602 is to be 

25 executed. 

If it is determined in decision 606 that an additional shading operation 602 is 
to be performed, another iteration 600 is executed. On the other hand, if no further 
shading operations are to be executed, the process of Figure 6 may be terminated. 
30 During use, the number of iterations may vary per the desires of the user. 
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As such, decision 604 allows additional texture infonnation to be retrieved in 
subsequent shading calculations 600 based on previously retrieved texture 
infonnation. It should be also noted that this may be done on different texture maps. 
In the alternative, it may be decided in decision 604 to not do a texture look-up, and 
5 merely perform a shading calculation 600 during a current iteration. 

As mentioned earlier during reference to Figure 4, the shading module 406 
may carry out many various types of operations in order to produce output of various 
types based on the edge distances (eo, e,. ez) generated by the rasterizer 404. Such 
10 output may include, but are not limited to diffuse output colors, fog output values, 
specular output colors, depth output values, texture color output values, a level of 
detail (LOD) value, and/or a Z-slope value. As an option, the calculation of a level 
of detail (LOD) may be perfonned based on the texture information that is 
previously retrieved. 



15 



20 



In order to accomplish the foregoing shading operations set forth in Figures 4 
and 6, perspective corrected barycentric weights (go, gi, gz) may be calculated from 
the edge distances (eo, e,, ez). In a first embodiment. Equations #1 are utilized to 
calculate the perspective barycentric weights (go, gi, 

Equations #1 



gO = eO*d 
gl =el*d 
g2 = e2*d, where 



s = e0*w0*wl+el*wl*w2+e2*w2*w0 
d = 1/s, where 

wO, wl and w2 are the perspective correction factors 
used to perform hyperbolic or perspective corrected 
interpolation 
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Figure 7 illustrates a point within a primitive that is capable of being defined 
by barycentric weights (go, gi, gi). In particular, point (p) may be defined by 
Equation #2 in terms of the barycentric weights (go, gi. &) and vertices (a, b, c) of 
the primitive. As an option, the perspective barycentric weights may use parameter 
values of the primitive in order to perform perspective corrected interpolation of 
vertex parameter values. Optionally, the perspective barycentric weights may use 
undipped parameter values. 

Equation #2 
p = a*go + b*gi +c*g2 



Given the perspective corrected barycentric weights (go, gi, the various 
hading calculations may be performed using the equations set forth in Table 1 . 



s 



Table 1 



Z in Screen Space(depth) - Calculate screen space z values at the vertices, then 
interpolate them per-pixel using the edge values as non-perspective corrected 

20 weights. 

zsO = zcO / wcO; zsl = zcl / wcl ; zs2 = zc2 / wc2. 
zs = (eOzsO + el zsl +e2 zs2 )/( eO + el +e2) 

25 Fog - Interpolate the fog range (may be affine xform of z eye, or distance from eye 

point ~ boA computed per vertex). 

Call fog range from xform fr. 
fr = gO*frO + gl*frl +g2*fr2 
30 then retrieve frac(fr) and run it through either: 

1) notable 

2) exp table 

3) exp''2 table 

Note: This table could be implemented as a texture map lookup. This would allow 
3 5 one to do an Opengl fog table. 

4 (or any other number oj) Non-projective 2-D Texture Coordinates - This 
optimization can only be done if all q's are one. Otherwise, the 2 projective case 
4Q below is performed. 
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s = gO*sO + gl*sl +g2*s2 
t = g0*t0 + gl*tl+g2*t2 



2-D Projective or Cube Texture Coordinates 
2-D: 

sq = gO*sO + gl*sl +g2*s2 

tq = gO*tO + gl*tl +g2*t2 

q = gO*qO + gl*ql + g2*q2, where 



qi= 1/q 
s = sq*qi 
t = tq*qi 



Cube: 

sr = gO*sO + gl*sl +g2*s2 
tr = g0*t0 + gl*tl+g2*t2 
rr = gO*rO + gl*rl+g2*r2 
f = pickmax(s,t,r) 



Note: f is a face index beginning at zero (for s). Pick is a function that chooses the 
fth entry from the list passed to it, where f is first parameter. 



sr = pick(f,tr,rr,sr) 
tr = pick(f,rr,sr,tr) 
r = pick(f,sr,tr,rr), where 



ri = 1/r 
s = sr*ri 
t = tr*ri 



3-D projective textures - 

sq = g0*s0 + gl*sl + g2*s2 

tq = gO*tO + gl*tH-g2*t2 

rq = g0*r0 + gl*rl+g2*r2 

q = gO*qO + gl*ql + g2*q2, where 

qi = 1/q 
s = sq*qi 
t = tq*qi 
r = rq*qi 



2-D dependent texture lookup - After the first texture lookup, two components of 
the ai^b color are reinterpreted as texture coordinates, and looked up again. 

Dx6 Bump Mapping - After the first texture look- up. color rO.gO.bO is received 
which is multiplied by 2x2 basis matrix, which is constant, si and tl are the 
interpolated texcoords for the second look-up. 

slp = mll*iO + ml2»gO + sl 
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tlp = m21*iO + m22*gO + tl 

After the second texture lookup, received is rl.gl.bl.al. 

f=(bO*ni31 +m32) 
rlp = r1*f 
glp = bl*f 
blp = bl*f 
alp = al 

Polygon Offset - let the notation z(l,0) indicate the z value of the pixel in the 
bottl ri^t comer of the pixel block, or quad. z(0,l) would be the top left, 
compute the z slopes: 

zxO = z(l,0)-z(0.0) 
zyO = z(0,l)-z(0,0) 
factor = max(abs(zxO),abs(zyO)) 

ZXl factoT*zs + units, where factor and units are state. Loaded with pipelined 
State bundles. 

Dot Product-based texture mapping - Using sO. tO. a first texture »ook_ up is 
performed. Call the results aO bO cO. Dot products are taken b«ween these values 
SndTsubsequent texture coordinates to generate a new set of texture coordinates 
for a subsequent texture lookup: 

sp = sl *aO + tl *bO + rl *cO 
tp = s2 * aO + 12 * bO + r2 * cO 

2- D texture lookup performed using (sp, tp ). 

or 

sp = sl *aO + tl *bO + rl * cO 
tp = s2*a0 + t2*b0 + r2*c0 
rp-s3*aO + t3*bO + r3*cO 

3- 0 texture lookup performed using (sp, tp, rp) 

Cube Texture coordinates performed (as above) using (sp, tp, rp) 



Reflective Bump Mapping - Using sO, tO, a first texture look-up is performed. Call 
the results hs,ht,hr. this is the normal in tangent space. 

interpolate si , tl , r 1 . - this is the surface tangent vector in eye space 
interpolate s2, t2, r2 this is the surface bmormal vector, 
interpolate s3, t3, r3 -- this is the surface normal vector. 

These are used as a basis matrix by which to multiply the vector hs,ht,hr. This 

will give the normal in eye space. 

so, 

nx = sl*hs + s2*ht + s3*hr; 
ny = tl*hs + t2*ht + t3*hr; 
nz = rl*hs + r2*ht + r3*hr; 
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use the (nx,ny.nz) vector as a cube map lookup for the diffuse lighting component. 

Now compute the reflection vector per pixel. 

let ne = nx*ex+ny*ey+nz*ez; 
let n2 = nx*nx + ny*ny + nz*nz; 
rx = 2*nx*ne/n2 - ex; 
ry=2*ny*ne/n2-eyi 
rz = 2*nz*ne/n2 - ez; 

Use this reflection vector as a cube map lookup. 

Depth Texture Mapping mth Dot Products - Using sO, tO, a first texture look-up is 
XnSd Call thfresults aO, bO, cO. Dot products are Perfo-ed b^^^^^^^^ Ojes 
values and two subsequent sets of texture coordmates to ^'^f^'^'^fl^^^^ 
IZL These quotient of these values replaces the previously calculated z screen 

value. 

zc = aO*sl+bO*tl+cO*rl; 
wc = aO * s2 + bO * t2 + cO * r2; 

zs = zc / wc 

P,v./r„///na-Thes t r and q coordinates for a particular texture are interpolated 
neToixf Each co^^^^^^^^ is ind.v.dually configured to check for either negat.ve or 
n^Xi ve va^^^^^^^ If the texture coordinate matches the conf.guraUon, the p.xel .s 

';^roTBTDF''l l^.. results of two texture coordinate lookups are interpreted as 
Sh numbers. hO. 10 and hi, 11. A third texture lookup is performed usmg (hO, hi. 
10-11). 

It Should be understood that each of the options set forth in the foregoing 
tables may be adapted to reuse common portions of the hardware set forth in Figure 
4. As set forth earlier, such hardware is capable of interpolating and performing 
texture address calculations during general operation. 

Table 1 is based on perspective corrected barycentric weights (go, gi. g2). In 
another embodiment, non-perspective corrected barycentric weights (go. g., gz) may 
be utilized which are defined in Equations #5. Non-perspective corrected 
barycentric weights replace perspective correct weights when texture coordinates, 
colors, depth, or fog are being interpolated. 

Fq uations #5 



gO = eO*d 
gl =el*d 
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g2 = e2*d, where 



s = e0-i-el+e2 
d= 1/s 



Figure 8 illustrates a graphics pipeline 800 with which a shadow mapping 
technique may be performed in accordance with one embodiment of the present 
invention. In such approach, there are two rendering passes 802 and 804, similar to 
the technique of Prior Art Figure 1. In the first pass 802, the scene is rendered from 
the point of view of a light source resulting in a depth map 806, or shadow map, and 
a polygon offset function is performed in operation 808, as set forth during reference 
to Prior Art Figure 1. 

hi addition, a clamping operation 810 may optionally be performed for 
clamping the depth value, z„ght . based on a slope threshold value. Additional 
information regarding the clamping operation 810 will be set forth during reference 
to Figure 9. By performing this clamping operation 810, one form of shadow 
aliasing is avoided in operations 812 and 814 of the second pass 804. 

Finally, a shadow modulation operation 816 is performed that is very flexible 
in that it employs the feedback architecture set forth in Figure 4. Additional 
information regarding the maraier in which the shadow modulation operation 816 is 
executed will be set forth during reference to Figure 11. 

Figure 9 illustrates a method 900 for shadow mapping while rendering a 
primitive in a graphics pipeline, as set forth in Figure 8. In one embodiment, the 
various operations associated with method 900 may be carried out by the shader 
module 406 and/or texture module 408 of Figure 4, or any other desired module. 

hiitially, in operation 902, an offset operation is performed in order to 
generate a depth value, i.e. z,igh,. while rendering a primitive. In one embodiment, 
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the offset operation may include the "PolygonOffset" operation in accordance with 
the OpenGL® programming language. It should be noted that in the present 
description, the term depth value may refer to a standard z-value, w-value, and/or 
any other depth-related dimension pertaining to the graphics arts. 

Thereafter, in operation 904, a value of a principle slope associated with a 
primitive is identified. Next, the depth value, zugh., is conditionally clamped based 
on the value of the slope, as indicated in operation 906. In particular, the depth 
value, ZHgh.. maybe clamped to the depth gamut of the primitive if the value of the 
slope is greater than a predetermined amount, namely a shadow slope threshold. 
This threshold may be determined by the graphics application being utilized, or by 
any other means per the desires of the user. Further, the shadow slope threshold may 
be set once per frame, or more often. During operation 906, the depth value, zugh,, 
may be clamped in different ways as determined in operation 808 of Figure 8. 

The purpose of conditionally clamping the offsetted value is to reduce 
artifacts caused by "edge-on" primitives. In the present description, an edge-on 
primitive refers to a primitive whose z gradients are large; i.e., exceed a specified 
threshold. In other embodiments, the depth value, z,igh,. generated by the offset 
operation may be compared to any predetermined vertex depth value associated with 
the primitive vertices, and clamped accordingly in order to prevent shadow aliasing. 
By limiting the depth value within each primitive after the offset operation is 
performed, the depth ambiguity between objects at different layers can be greatly 
reduced, and the ghost shadow artifacts may be eliminated very effectively. 
However, applications need not perform this operation. 

Recall the computation of zught from Equations A: 

F qiiatinns A (set forth hereinabove) 

ziight = z + 0, where: 
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o = m*factor + r*units, where: 



m = max(abs(5z/5x), abs(5z/5y)), 

5 

Figure 9a illustrates the manner in which the depth value, z.ight, is clamped m 
operation 906 of Figure 9. As shown, the clamping includes initially identifying 
vertex depth values, zo,z„z,.ofvertices of the primitive. Note operation 950. It 
should be noted that any number of vertex depth values may be identified based on 
10 the nature of the primitive. 

Thereafter, at decision 952 it is decided whether any modification to the 
computed polygon-offsetted zh,h. value is desired. If the slope m computed as an 
intermediate value in the polygon offset operation is not greater than the application- 
15 specified shadow slope threshold, no modification is done. Otherwise, control 
proceeds to decision 954. 

. If it is decided in decision 954 that the depth buffer depth compare operation 
is < (LESS THAN) or <= (LESS THAN OR EQUAL TO), the offsetted value, zugh., 
20 generated by the offset operation may be clamped to the minimum of z„gh, and the 
greatest vertex depth value, max(zo, z., z^). See operation 956. Equation #6 
illustrates the equation by which operation 956 is carried out. 

Eq uation #6 

25 

ziight= min[ziight, max(zo, zi, Z2)] 

Otherwise, if it is decided in decision 958 that that the depth buffer depth 
compare operation is > (GREATER THAN) or >= (GREATER THAN OR EQUAL 
30 TO), the offsetted value. z„gh., generated by the offset operation may be clamped to 
the maximum of the z„gh. and the smallest vertex depth value. min(zo. z,, Z2). See 
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„pera,io„960.E<,ua.io„#7i— tee,»aS<».bywhichop=»«o„960isc.rried 
out. 

Kq uation #7 

5 

Zlight = max[ziight, min(zo, zi, zi)] 
Otherwise, ziight is not modified. 

10 Figure 10 is a diagram illustrating the manner in which the depth value, z„gHt. 

is clamped in accordance with the method of Figure 9. As shown, the depth value, 
z,. generated by the offset operation may be clamped to min(zo, z. za) or max(zo, 
z'z.), thus preventing erroneous results when employingthe offset operation 902 of 



15 



Figure 9. 



Figure 11 illustrates a method 1100 for performing shading calculations m a 
graphics pipeUne in accordance with one embodimentofthe present invention. 

taitially, in operation 1102 a first shading calculation may be performed m order to 
generate output, after which such output may be saved in operation 1 104 . A second 
20 shadingcalculationmayalsobeperformedinoperationll06usingtheprevious 

output in order to generate further output. In one embodiment, the vanous 
operations associated withmethodllOO may be carried outby the shadermodule 

406 and/or texture module 408 of Figure 4, or any other desired module. 



25 



30 



As an option, the first shading calculation may include: 
[(l-s)*(Color_diff + Color_spec)] 
for generating an output A, and the second shading calculation includes: 

[Color__amb + A], 
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where s is a shadow variable. Color_diff is a diffuse color variable. Color.spec is a 
specular color variable, and Color_amb is an ambient color variable. 

In another embodiment, the first shading calculation may include: 

[((1-s)* Color_diff) + Color_amb] 

for generating an output A. and the second shading calculation includes: 

[A*Texture_det + (1-s)* Color_spec]. 



where s is a shadow variable, Color_diff is a diffuse color variable, Color_spec is a 
specular color variable, Color_amb is an ambient color variable, and Texture.det is 
15 a texture detail variable. 

As such, the first and second shading calculations may together include a 
diffuse color variable, a specular color variable, and an ambient color variable. Such 
variables are further decoupled which allows very flexible shadowing operations, 
20 including but not restricted to the shadows generated by semi-transparent objects, 
anti-shadows, etc. 

While various embodiments have been described above, it should be 
understood that they have been presented by way of example only, and not 
25 limitation. Hius, the breadth and scope of a preferred embodiment should not be 
limited by any of the above described exemplary embodiments, but should be 
defined only in accordance with the following claims and their equivalents. 
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